Skip to content

fix: reject Windows file paths in can_parse #957

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

mertcanaltin
Copy link
Contributor

reject Windows file paths in can_parse

I tried to solve this place out : nodejs/node#58578 (comment)

Comment on lines +53 to +55
if (helpers::is_windows_file_path(input)) {
return false;
}
Copy link
Member

@anonrig anonrig Jun 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you point us to where in the URL spec this is returning false? Chrome and Safari returns true...

> URL.canParse("file:///C:/path/file.node")
true
> URL.canParse("C:\\path\\file.node")
true

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually allowed. https://url.spec.whatwg.org/#file-host-state

If state override is not given and buffer is a Windows drive letter, file-invalid-Windows-drive-letter-host validation error, set state to path state.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you apply the same change to URL parser, not the can_parse() method, you'll see that it breaks web-platform tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you, instead of rejecting Windows file paths
Is it a healthy method to normalize them with the file:/// protocol ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What the library provides is WHATWG URL support. If the result disagrees with your expectations make sure first to check the WHATWG URL specification. If you disagree with it, you should take your concerns with WHATWG.

We may have bugs but a bug is a disagreement with WHATWG.

@anonrig anonrig requested review from lemire and jasnell June 13, 2025 19:17
@lemire
Copy link
Member

lemire commented Jun 13, 2025

At a glance this PR appears to break the specification.

@mertcanaltin
Copy link
Contributor Author

At a glance this PR appears to break the specification.

@lemire Thank you for the clear guidance. I understand now that we should follow the WHATWG URL spec strictly.

I've opened an issue in WHATWG to discuss the Windows file path handling: whatwg/url#873

I'll keep the library's behavior aligned with the spec while we discuss this in WHATWG.

@lemire
Copy link
Member

lemire commented Jun 13, 2025

I am closing this PR since @mertcanaltin reported the issue to WHATWG. It is understood that if the standard changes, we will reopen such a PR.

@lemire lemire closed this Jun 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants